The regex here removes numeric attributes and removes them.

The problem is that it's also special-casing numeric attributes, so I can no longer use 0 as an attribute (as unlikely as that is).

You can, unnamed attributes in WP are placed as numeric keys in the $attr variable during shortcode parsing. So I from what I can tell unnamed & numeric are treated the same way in WP. So there shouldn't be any problems.

Tested this using Jetpack's googlemaps shortcode:

/**
 * [googlemaps] shortcode
 *
 * Example usage:
 *   [googlemaps http://maps.google.com/maps?f=q&hl=en&geocode=&q=San+Francisco,+CA&sll=43.469466,-83.998504&sspn=0.01115,0.025942&g=San+Francisco,+CA&ie=UTF8&z=12&iwloc=addr&ll=37.808156,-122.402458&output=embed&s=AARTsJp56EajYksz3JXgNCwT3LJnGsqqAQ&w=425&h=350]
 *   [googlemaps https://mapsengine.google.com/map/embed?mid=zbBhkou4wwtE.kUmp8K6QJ7SA&w=640&h=480]
 */
function jetpack_googlemaps_shortcode( $atts ) {
    if ( !isset($atts[0]) )
        return '';

    $params = ltrim( $atts[0], '=' );

    var_dump( $atts[0] );

    // didn't paste the rest of the code

The var_dump( $atts[0] ) there returned the correct attribute after the preg_replace ran.

Also related - #128

I'm not sure how we would tackle this.

EDIT - Oh - I see you already commented on this.

Did some tests and it seems that this PR just solves part of the problem. Will get back with an explanation.

I think we should have some unit test coverage here.

After extensive testing and debugging, I'm revamping my fix for this. I think this is the right way to approach this.

The real problem: unnamed attributes are not recognized by the editor views & the UI

I removed my initial commit with the regex, and now the views recognize the unnamed attributes.

The fix is to handle unnamed attributes as numeric ones. That means:

array(
   'label' => '',
   'attr'  => '0',
   'type'  => 'text',
   'value' => 'value1'
),
array(
   'label' => '',
   'attr'  => '1',
   'type'  => 'text',
   'value' => 'value2'
),

Will now generate:

[shortcode "value1" "value2"]

WordPress/PHP-wise, these attributes are accessible using the normal $attr[0] and $attr[1]

The fix is not yet complete. The only thing missing now is that editing an existing shortcode turns the attribute input fields blank, like the values are not being found.

The last part of the solution may be is to add another regex at the function sui.utils.shortcodeViewConstructor.edit to check for unnamed attribute values, then do an attr.set on those. TBH, I'm having trouble with figuring out a clean regex for this. Will continue trying in the morning if nobody solves this :)

Alright, finally finished the fix. I'm very well pleased with the results.

Closing and doing a new cleaner PR #198, since this now has tons of conflicts.

now has tons of conflicts.

We just landed some big changes to the structure of the JS. Apologies for the conflicts!

Apologies for the conflicts!

No problem! It's about time I tried to learn how to use grunt.